RAII things - #759

SQLite pools now build through CountingSqliteManager, and the build sites
in get_or_create_shared_pool report creation and cache reuse.

census_workload, ten surfnets built and dropped per phase:

    on-disk:   pools 10 (+180 reuses), conns opened 100, closed 0,
               100 still live after the last drop
    in-memory: pools 190, conns opened 1,900, closed 1,900,
               peak 190 live during one surfnet

Connections owned by the process-global SHARED_POOLS survive every
surfnet drop. The in-memory line prices the 19 isolated pools each
surfnet builds.

…ions

Each surfnet now opens one StorageBackend from its database URL and mints
all of its kv stores from it. The SQLite pool moves off the process-global
SHARED_POOLS map onto the backend, so connections live exactly as long as
the surfnet that opened them; the checkpoint-dedup set and the per-store
shutdown fan-out fall away with it. PostgreSQL keeps its process-level
pool cache behind the backend, where pooling actually amortizes a network
connection. In-memory SQLite now shares one database per surfnet instead
of building 19 isolated pools, matching the on-disk layout of distinct
tables in one database.

The counting manager remains the pool's connection type, so connection
opens and closes stay counted; the census build-site hook is reconnected
in the next commit.

SqliteBackend::open reports pool creation, and a new assertion test,
dropping_backend_closes_connections, fails if any connection opened by a
backend survives its drop.

census_workload, same workload as the baseline measurement two commits
back:

    on-disk:   pools 10, conns opened 100, closed 100, live 0
    in-memory: pools 10, conns opened 100, closed 100, live 0

Ten dropped surfnets leave 100 connections live on the baseline and none
here; in-memory construction opens 190 connections per surfnet there and
10 here.